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Abstract. When configuring customizable software, it is useful to pro- 
vide interactive tool-support that ensures that the configuration does not 
breach given constraints. But, when is a configuration complete and how 
can the tool help the user to complete it? We formalize this problem 
and relate it to concepts from non-monotonic reasoning well researched 
in Artificial Intelligence. The results are interesting for both practition- 
ers and theoreticians. Practitioners will find a technique facilitating an 
interactive configuration process and experiments supporting feasibility 
of the approach. Theoreticians will find links between well-known formal 
concepts and a concrete practical application. 

1 Introduction 

Software Product Lines (SPLs) build on the assumption that when developing 
software-intensive systems it is advantageous to decide upfront which products 
to include in scope and then manage construction and reuse systematically [4]. 

This approach is suitable for families of products that share a significant 
amount of their user-visible or internal functionality. Parnas identified such pro- 
gram families as: ... sets of programs whose common properties are so extensive 
that it is advantageous to study the common properties of the programs before 
analyzing individual members. [20] 

A key aspect of SPLs is that the scope of products is defined and described 
explicitly using models of various expressivity [14,1,23,10]. Conceptually, we can 
consider an SPL as a mapping from a problem space to a solution space. The 
problem space comprises requirements that members of the product line satisfy, 
and, the solution space comprises possible realizations, e.g., programs in C ++ . 
These spaces are defined by some constraints, i.e., requirements or solutions 
violating the constraints are not within the respective space. 

A specification for a new product is constructed from the requirements which 
must be matched to the constraints that define the scope of the product line. 
In effect, the purchaser picks a particular member of the problem space. Subse- 
quently, software engineers are responsible for delivering a product, a member 
of the solution space, corresponding to the given specification. 



Fig. 1: FODA notation and Configuration Processes 
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If the problem space is complex, picking one of its members is not trivial. 
Hence, we strive to support interactive configuration with configurator tools. De- 
spite the fact that this has been researched extensively (see [17,8,1,24,11,9]), little 
attention has been paid to the completion of a configuration process. Namely, 
how shall we treat variables of the configuration model that have not been bound 
by the user at all? (This issue has been noted by Batory in [1, Section 4.2]). 

This article studies this problem (Sect. 2.2) and designs an enhancement of a 
configurator that helps the user to get closer to finishing the configuration process 
by binding variability without making decisions for the user, i.e., it is aiming 
at not being overly smart. The article focuses mainly on this functionality for 
propositional configuration (Sect. 3) and it relates to research on Closed World 
Assumption (Sect. 3.4). The general, non-propositional, case is conceptualized 
relying on the notion of preference (Sect. 4). 



2 Background and Motivation 

Kang et al. developed a methodology Feature Oriented Domain Analysis 
(FODA), where feature models are used to carry out domain analysis — a system- 
atic identification of variable and common parts of a family of systems [14]. For 
the purpose of this article, it is sufficient to consider a feature as "a prominent 
or distinctive user-visible aspect, quality, or characteristic of a software system 
or system" [14], and a product as a combination of its features. A Software 
Product Line is a system for developing products from a certain family captured 
as a set of feature combinations defined by a feature model. The semantics of 
a feature model is typically defined with propositional logic. Each feature / is 
represented by a propositional variable v/ and a Boolean formula is constructed 
as a conjunction of formulae representing the different modeling primitives. The 



satisfying assignments of the resulting formula define the set of possible fea- 
ture combinations [23]. A popular notation is the FODA notation [14] with the 
primitives in Fig. 2a exemplified by Fig. 2b whose semantics is in Fig. 2c. The 
corresponding feature combinations, defining the problem space, are listed in 
Fig. 2d. The FODA notation has several extensions, e.g., feature attributes rep- 
resent values such as price. For general attributes, Boolean logic is insufficient 
and the semantics is expressed as a Constraint Satisfaction Problem [2] . 

2.1 Configuration Process 

In the interactive configuration process, the user specifies his requirements step- 
by-step, gradually shrinking the problem space (see Fig. 2e). Hence, this process 
can be seen as a step-wise refinement of the constraint defining the space [5,11]. 
How the problem space is refined in each step is called a decision. 

A configurator is a tool that displays the model capturing the constraints, 
presents the user with possible (manual) decisions, and infers necessary (auto- 
matic) decisions. The tool discourages the user from making decisions inconsis- 
tent with the constraints, and, it suggests decisions that are necessary to satisfy 
the constraints. For convenience, configurators enable the user to retract previ- 
ously made decisions; some even enable to temporarily violate the constraints 
but this is out of the scope of this article and gradual refinement will be assumed. 

For illustration consider the feature model in Fig. 2b and the following steps 
(see Fig. 2d). (1) The user selects the feature a. This implicitly deselects b as a 
and b are in an xor-group and there are no feature configurations with both a 
and b. (2) The user selects the feature c, which has no further effects. (3) Finally, 
he deselects the feature d and the process is completed since exactly one feature 
combination is left, i.e., each feature is cither in the product or not. 

In summary, the input to the configurator is a constraint defining a large set 
of possibilities — the outermost ellipse in Fig. 2c. Gradually, this set is shrunk 
until exactly one possibility is left (assuming the user succeeded). 

2.2 Completing a Configuration Process and the Shopping Principle 

The concepts introduced in the previous sections are well known [8]. However, 
the configuration literature does not study the completion of a configuration 
process. As stated above, at the end of the process the decisions must determine 
exactly one feature combination (the innermost ellipse in Fig. 2e). So, how does 
the user achieve this? This article introduces the following classification. 

M (Manual). The user makes decisions up to the point when all considered 
variables have been bound, i.e., each variable has been assigned a value by the 
user or by a decision inferred by the configurator. The disadvantage of this 
approach is that the user needs to fill in every single detail, which is cumbersome 
especially if there are some parts of the problem that are not of a high relevance 
to the user. The only assistance the tool provides is the mechanism that infers 
new decisions or disables some decision. We will not discuss this case further. 



A (Full blind automation) . A function automatically computes some values for 
all variables that do not have a value yet. The disadvantage of this option is that 
it takes all the control from the user as it is essentially making decisions for him. 

A + (Smart automation) . If we assume some form of an a priori, common sense 
assumptions, there is an approach somewhere between the options M and A. 
In the example above, the user had to explicitly deselect the optional feature d 
but would it be possible to instead say that all features not selected should be 
deselected? The motivation for this approach can be explained by an analogy 
with shopping for groceries (thus the shopping principle). The customer asks 
only for those items that he wants rather than saying for each item in the store 
whether he wants it or not. If some variables cannot be bound according to 
this principle, due to some dependencies, the tool will highlight them since it is 
possible that the user forgot to make a certain decision, e.g., we wouldn't want 
the tool to decide between features in an xor-group (a and b). 

In some sense, the scenario A + is a more careful version of scenario A. Both 
support the user to complete the configuration process. Scenario A binds all 
variables, whereas A + only those for which this doesn't mean deciding something 
for the user. The following section investigates these scenarios in constraints 
defined as Boolean formulae (recall that FODA produces Boolean formulas). 

3 Propositional Configuration 

First, let us recall some basic terms from propositional logic. Let V be some 
finite set of variables. The propositional formulae discussed from now on will be 
only on these variables. A variable assignment assigns either true or false to 
each considered variable. Often it is useful to think of a variable assignment as 
the set of variables that are assigned the value true, e.g., the variable assignment 
x i ► true, y i— > false corresponds to the set {x} in the set-based notation. 

A model of a formula <fi is such a variable assignment under which <p evaluates 
to true. We say that the formula (j> is satisfiable, denoted as Sat(</>), if and only 
if <fi has at least one model, e.g., the formula x V y is satisfiable whereas the 
formula x A ~^x is not. We write (p \= ip to denote that the formula ip evaluates 
to true under all models of 0, e.g., it holds that x A y |= x. 

3.1 Propositional Configuration Process 

In order to reason about the feature model and the user's requirements, the con- 
figurator translates them in some form of mathematical representation. In this 
section we assume that the model has already been translated into propositional 
logic (see Fig. 2c for illustration). 

Definition 1. A propositional configuration process for some finite set of vari- 
ables V and a satisfiable propositional formula <f> only on the variables from V is 
a sequence of propositional formulce (f>o, ■ ■ ■ , 4>k such that 4>o — 4>, 4>i+i — <Pi A Ci 



for all i G . . . k— 1, and 0^ is satisfied by one variable assignment. The formul<£ 
£i are decisions made by the user or decisions inferred by the configurator. If £j 
is of the form v for some variable v G V, then we say that the variable v has been 
assigned the value true in step i; if £j is of the form ->v, we say that it has been 
assigned the value false in step i. Observe that fa+i fa for all i G ... fc — 1, 
i.e., the set of models is shrunk along the process. 

Example 1 . Let fa = (—>u V ->v) A (x =4> y) . The user sets u to true (fa = fa A u) ; 
the configurator sets v to false as u and v are mutually exclusive (fa = fa A ->v). 
The user sets y to false (fa = fa A ->y); the configurator sets x to false (04 = 
03 A The process is finished as all variables were assigned a value. 

The inference mechanism of the configurator typically inspects for all vari- 
ables v £ V whether 0/ |= v, in which case it sets v to true, and whether 0; |= ->v, 
in which case it sets v to false. If a value has been inferred, the user is discour- 
aged by the user interface to change it ("graying out"). This can be computed 
with the help of a SAT solver [9] or Binary Decision Diagrams (BDDs) [8]. 

3.2 Completing a Propositional Configuration Process 

Let us look at the scenarios for completing a propositional configuration process. 
Earlier, we have identified two types of functions that the user may invoke at 
any step of the process: (A) a function that binds all the remaining variables; 
(A + ) a function that finds values for only some variables according to an a priori 
knowledge; we call this function a shopping principle function. 

The case A is straightforward, finding a solution to the formula fa in step i 
is a satisfiability problem which can be solved by a call to a SAT solver or by a 
traversal of a BDD corresponding to fa (see [9,8] for further references). 

The scenario A + , however, is more intriguing. The a priori knowledge that we 
apply is the shopping principle (see Sect. 2.2), i.e., what has not been selected 
should be false. According to our experience and intuition (as well as other 
researchers [1, Section 4.2]), this is well in accord with human reasoning: the 
user has the impression that if a variable (a feature in a feature model) has not 
been selected, then it should be deselected once the process is over. 

However, it is not possible to set all unassigned variables to false in all cases. 
For instance, inuVvwe cannot set both u and v to false — the user must choose 
which one should be true, and we do not want to make such decision for him 
(otherwise we would be in scenario A). Another way to see the problem is that 
setting u to false will force the variable v to be true, and vice-versa. If we consider 
the formula x ^{y V z), however, all the variables can be set to false at once and 
no further input from the user is necessary. 

In summary, the objective is to maximize the set of variables that can be 
set to false without making any decisions for the user, i.e., variables that can be 
deselected safely. Upon a request, the configurator will set the safely-deselectable 
variables to false and highlight the rest as they need attention from the user. 



3.3 Deselecting Safely 



We start with an auxiliary definition that identifies sets of variables that can be 
deselected at once. This definition enables us to specify those variables that can 
be deselected safely; we call such variables dispensable variables (we kindly ask 
the reader to distinguish the terms deselectable and dispensable). 

Definition 2 (Deselectable). A set of variables X C V is deselectable w.r.t. 
the formula ip, denoted as T>(ip,X), iff all variables in X can be set to false at 
once. Formally defined as T)(ip, X) = Sat (ip A /\ v ex ~ nV ) • Analogously, a single 
variable v G V is deselectable w.r.t. the formula ip iff it is a member of some 
deselectable set of variables, i.e., T>(ip,v) = Sat(-0 A ->v). 

Definition 3 (Dispensable variables). A variable v E V is dispensable w.r.t. 
a formula ip iff the following holds: (VI C V) (V(ip,X) =$-T>(ip A X)). 

In plain English, a variable v is dispensable iff any deselectable set of vari- 
ables X remains deselectable after v has been deselected (set to false). Intuitively, 
the deselection of v does not force selection of anything else, which follows the 
motivation that we will not be making decisions for the user. In light of the 
shopping principle (see Sect. 2.2), a customer can skip a grocery item only if 
skipping it does not require him to obtain some other items. The following ex- 
amples illustrate the two definitions above. 

Example 2. Let <p = f (u V v) A (x y). Each of the variables is deselectable but 
only x and y are dispensable. The set {x,y} is deselectable, while the set {u, v} 
is not. The variable u is not dispensable as {v} ceases to be deselectable when u 
is set to false; analogously for v. The variable x is dispensable since after x has 
been deselected, y can still be deselected and the variables u, v are independent 
of x's value. Analogously, if y is deselected, x can be deselected. 

Observe that we treat true and false asymmetrically, deselecting y forces x 
to false, which doesn't collide with dispensability; deselecting u forces v to true 
and therefore u is not dispensable. 

Example 3. Let <j> be defined as in the previous example and the user is perform- 
ing configuration on it. The user invokes the shopping principle function. As x 
and y are dispensable, both are deselected (set to false). The variables u and v 
are highlighted as they need attention. The user selects u, which results in the 
formula cp\ = <fi A u. The variable v becomes dispensable and can be deselected 
automatically. The configuration process is finished as all variables have a value. 

As we have established the term dispensable variable, we continue by study- 
ing its properties in order to be able to compute the set of dispensable variables 
and to gain more intuition about them. 

Lemma 1. Let denote the set of all dispensable variables of (p. For a satis- 
fiable ip, the dispensable variables can be deselected all at once, i.e., T){ip,T§). 



Proof. By induction on the cardinality of subsets of T^. Let To = 0, then 
T>(ip,Y ) as i> is satisfiable. Let Ti,T i+1 C T^, s.t. T i+1 = T; U{x}, = i, and 
|Tj_|_x | = i + 1- Since x is dispensable and 2?(0, then T>(<fi A -ia;, T;), which is 
equivalent to T>(cf), Ti U{x}). 

The following lemma reinforces that the definition of dispensable variables 
adheres to the principles we set out for it, i.e., it maximizes the number of 
deselected variables while not arbitrarily deciding between variables. 

Lemma 2. The set — the set of all dispensable variables of 4> — is the inter- 
section of all maximal sets of deselectable variables of <j). 

Proof (sketch). From definition of dispensability, any deselectable set remains 
deselectable after any dispensable variable is added to it, hence is a subset of 
any maximal deselectable set. is a maximal set with this property because for 
each deselectable set that contains at least one non-dispensable variable there is 
another deselectable set that does not contain this variable. 

3.4 Dispensable Variables and Non-monotonic Reasoning 

After defining the shopping principle in mathematical terms, the authors of this 
article realized that dispensable variables correspond to certain concepts from 
Artificial Intelligence as shown in this subsection. 

The Closed World Assumption ( CWA ) is a term from logic programming 
and knowledge representation. Any inference that takes place builds on the as- 
sumption that if something has not been said to be true in a knowledge base, 
then it should be assumed false. Such reasoning is called non-monotonic as an 
increase in knowledge does not necessarily mean an increase in inferred facts. 
In terms of mathematical logic, CWA means adding negations of variables that 
should be assumed false in the reasoning process. Note that not all negateable 
variables (0 Y- v) can be negated, e.g., for the formula x V y both x and y are 
negateable but negating both of them would be inconsistent with the formula. 

The literature offers several definitions of reasoning under Closed World As- 
sumption [3,7]. A definition relevant to this article is the one of the Generalized 
Closed World Assumption (GCWA) introduced by Minker [19] (see [3, Def. 1]). 

Definition 4. The variable v is free of negation in the formula <j> iff for any 

positive clause B for which <$>¥■ B, it holds that <$>¥■ v V B. The closure C(<f>) of 
a formula <f> is defined as C((f>) = <pU {^K | K is free for negation in <fi}. 

It is not difficult to see that dispensable variables are those that are free of 
negation as shown by the following lemma. 

Lemma 3. Dispensable variables coincide with those that are free of negation. 

Proof. Observe that <f> ¥ ip iff Sat(</> A - >V')> then the definition above can be 
rewritten as: For B' = A v ev B ^ or some se ^ °f variables Vb for which Sat(0A 
B'), it holds that Sat(0 A A B'). According to the definition of V, this is 
equivalent to T>(<p, Vb) => V{<j> A ->v, Vb) (compare to Definition 3). 



Table 1: Experimental Results 



Name 


Features 


Clauses 


Length 


Done 


Minimal models 


tightvnc 


21 


22 


5.5 


5.5 


1.0 ±0.0 


apl 


27 


41 


12.2 


11.9 


1.0 ±0.0 


gg4 


58 


139 


10.0 


3.8 


15.3 ±22.6 


berkeley 


94 


183 


26.6 


17.9 


1.7 ±1.1 


violet 


170 


341 


56.1 


47.1 


1.6 ±0.9 



Circumscription, in our case the propositional circumscription, is another 
important form of reasoning [18]. A circumscription of a propositional formula (f> 
is a set of minimal models of <fi. Where a model a of a formula <f> is minimal iff <p 
has no model a' which would be a strict subset of a, e.g., the formula xVy has the 
models {x}, {y}, {x, y} where only {x} and {y} are minimal. We write 4> \=min ip 
to denote that ip holds in all minimal models of 4>, e.g., x V y |= m i n ~>(a: A y). 

The following lemma relates minimal models to dispensable variables (The 
proof of equivalence between minimal models and GCWA is found in [19]). 

Lemma 4. A variable v is dispensable iff it is false in all minimal models. 

Example 4- Let tfio = (u V v) A (x => y). The minimal models of the formula <fio 
are {it}, {v}, hence 4>q \= m i n ~^x and cj>o \= min Then, if the user invokes the 
shopping principle function, x and y are deselected, i.e., 4>\ = 4>q A^xA^y. And, 
the user is asked to resolve the competition between uVw, he selects u, resulting 
in the formula <j>2 = 4>\ Au with the models {u} and {u, v} where only the model 
{u} is minimal hence v is set to false as dispensable. The configuration process 
is complete because u has the value true and the rest are dispensable. 

3.5 Experimental Results 

The previous section shows that dispensable variables can be found by enumer- 
ating minimal models. Since the circumscription problem is 77.f -complete [7] it is 
important to check if the computation is feasible in practice. We applied a simple 
evaluation procedure to five feature models 4 : For each feature model we simu- 
lated 1000 random manual configuration processes (scenario M). At each step 
we enumerated minimal models. (Algorithmic details can be found online [12].) 
We also counted how many times there was exactly one minimal model: At those 
steps the configuration process would have been completed if the user invoked 
the shopping principle function. 

The results appear in Table 1. The column Length represents the number 
of user decisions required if the shopping principle function is not invoked; the 
column Done represents in how many steps an invocation of the shopping prin- 
ciple function completes the configuration; the column Minimal models shows 
that the exponential worst case tends not to occur in practice and therefore 
enumeration of all minimal models is feasible. 

4 from http : //fm. gsdlab . org/ index .php?title=Model : SampleFeatureModels 



4 Beyond Boolean Constraints 

The previous section investigated how to help a user with configuring preposi- 
tional constraints. Motivated by the shopping principle, we were trying to set as 
many variables to false as possible. This can be alternatively seen as that the 
user prefers the undecided variables to be false. 

This perspective helps us to generalize our approach to the case of non- 
propositional constraints under the assumption that there is some notion of 
preference between the solutions. First, let us establish the principles for pref- 
erence that are assumed for this section. (1) It is a partial order on the set in 
question. (2) It is static in the sense that all users of the system agree on it, e.g., 
it is better to be healthy and rich than sick and poor. (3) If two elements are 
incomparable according to the ordering, the automated support shall not decide 
between them, instead the user shall be prompted to resolve it. 

To be able to discuss these concepts precisely, we define them in mathematical 
terms. We start by a general definition of the problem to be configured, i.e., the 
initial input to the configurator, corresponding to the set of possibilities that the 
user can potentially reach — the outermost ellipse in Fig. 2e. 

Definition 5 (Solution Domain). A Solution Domain (SD) is a triple 
(V, T>, <j>) where V is a set of variables V — . . . , v n }, T> is a set of respective 
domains T> = {D\, . . . , D n }, and the constraint <p C D± x • • • x D n is an n-ary 
relation on the domains (typically defined in terms of variables from V). 

A variable assignment is an n-tuple (ci, . . . ,c„) from the Cartesian product 
D\ x ■ • • x D ni where the constant Ci determines the value of the variable Vi 
for i € 1 . . . n. For a constraint ip, a variable assignment a is a solution iff it 
satisfies the constraint, i.e., a £ if). 

An Ordered Solution Domain (OSD) is a quadruple (V, T>, <fi, -<) where 
(V, T>, <fi) is an SD and -< is a partial order on D± x ■ ■ • x D n . For a constraint 
ip, a solution a is optimal iff there is no solution a' of ip s.t. a' =/= a and a' -< a. 

Recall that the user starts with a large set of potential solutions, gradu- 
ally discards the undesired ones until only one solution is left. From a formal 
perspective, solution-discarding is carried out by strengthening the considered 
constraint, most typically by assigning a fixed value to some variable. 

Definition 6 (Configuration Process). Given a Solution Domain (V, T>, cp), 
an interactive configuration process is a sequence of constraints (f>o, . . . , <pk such 
that = <p and \(j>k\ = 1- The constraint (j>j+i is defined as 4>j+\ — 4>j^£,j 
where the constraint £j represents the decision in step j for j G 0. . . k — 1. If £j 
is of the form Vi = c for a variable and a constant c £ Di, we say that the 
variable m has been assigned the value c in step j. Observe that 4>j+i C <f>j for 
j G . . . k — 1 and <j>j C (ft for j G . . . k. 

A configurator in this process disables certain values or assigns them auto- 
matically. In particular, the configurator disallows selecting those values that are 
not part of any solution of the current constraint, i.e., in step I it disables all 



values c € Di of the variable Vi for which there is no solution of the constraint 
(f>l of the form (c±, . . . , c, . . . c„). If all values but one are disabled for the domain 
Di, then the configurator automatically assigns this value to the variable Uj. 

Now as we have established the concept for general configuration, let us 
assume that a user is configuring an Ordered Solution Domain (Definition 5) and 
we wish to help him with configuring variables that have lesser importance for 
him, similarly as we did with the shopping principle. The configuration proceeds 
as normal except that after the user configured those values he wanted, he invokes 
a function that tries to automatically configure the unbound variables using the 
given preference. 

The assumption we make here is that the variables that were not given a 
value yet should be configured such that the result is optimal while preserving 
the constraints given by the user so far. Since the preference relation is a partial 
order, there may be multiple optimal solutions. As we do not want to make a 
choice for the user, we let him focus only on optimal solutions. 

If non-optimal solutions shall be ruled out, the configurator identifies such 
values that never appear in any optimal solution to reduce the number of deci- 
sions that the user must focus on. Dually, the configurator identifies values that 
appear in all optimal solutions, the following definitions establish these concepts. 

Definition 7 (Settled variables.). For a constraint tp and a variable Uj, the 
value c £ Di is non-optimal iff the variable Vi has the value c only in non-optimal 
solutions of iJj (or, has a different value from c in all optimal solutions of ip). 
A value c is settled iff Vi has the value c in all optimal solutions of tp. A variable 
vi is settled if there is a settled value of Vi. 

Observation 1 For some constraint and the variable Vi, a value c € Di is 
settled iff all values c' G Di different from c are non-optimal. 

Example 5. Let x,y,z £ {0, 1}. Consider a constraint requiring that at least one 
of x,y,z is set to 1 (is selected). The preference relation expresses that we prefer 
lighter and cheaper solutions where x, y, and z contribute to the total weight by 
1, 2, 3 and to the total price by 10, 5, and 20, respectively. Hence, the solutions 
satisfy (x + y + z > 0), and (aii, yi, Zi) ~< (x2, j/2, %2) iff (10xi + 5yi + 20zi < 
10x2 + 5j/2 + 20z 2 ) A {lx\ + 2yi + 3zi < 1x2 + 2^2 + 3z 2 ). Any solution setting 
z to 1 is non-optimal as z is more expensive and heavier than both x and y, 
and hence the configurator sets z to (it is settled). Choosing between x and 
y, however, needs to be left up to the user because x is lighter than y but more 
expensive than y. 

Propositional configuration, studied in the previous section, is a special case 
of a Solution Domain configuration with the variable domains {true, false}. The 
following observation relates settled and dispensable variables (definitions 7, 3). 

Observation 2 For a Boolean formula understood as an OSD with the prefer- 
ence relation as the subset relation, a variable is settled iff it is dispensable or 
it is true in all models (solutions). Additionally, if each variable is settled, the 
invocation of the shopping principle function completes the configuration process. 



This final observation is an answer to the question in the title, i.e., configu- 
ration may be completed when all variables are settled. And, according to our 
experiments this happens frequently in practice (column Done in Table 1). 

5 Related Work 

Interactive configuration as understood in this article has been studied e.g., by 
Hadzic et al. [8], Batory [1], and Janota [9]. In an analogous approach Jan- 
ota et al. [11] discuss the use of interactive configuration for feature model con- 
struction. The work of van der Meer et al. [24] is along the same lines but 
for unbounded spaces. Lottaz et al. [17] focus on configuration of non-discrete 
domains in civil engineering. 

There is a large body of research on product configuration (see [22] for an 
overview) , which typically is conceptualized rather as a programming paradigm 
than a human-interaction problem. Moreover, the notion rules are used instead 
of formulae. Similarly as do we, Junker [13] applies preference in this context. 
We should note that preference in logic has been studied extensively, see [6]. 

The problem how to help the user to finish the configuration process was 
studied by Krebs et al. [16] who applied machine learning to identify a certain 
plan in the decisions of the user. 

Circumscription has been studied extensively since the 80's [18,19,7]. Calcula- 
tion of propositional circumscription was studied by Rcitcr and Kleer [21]; calcu- 
lation of all minimal models by Kavvadias et al. and work referenced therein [15]. 

6 Summary 

This article proposes a novel extension for configurators — the shopping principle 
function (Sect. 3.2). This function automates part of the decision-making but is 
not trying to be too smart: it does not make decisions between equally plausible 
options. The article mainly focuses on the propositional case, as software engi- 
neering models' semantics are typically propositional. The relation with GCWA, 
known from Artificial Intelligence, offers ways how to compute the shopping 
principle function (Sect. 3.4). Several experiments were carried out suggesting 
that the use of the shopping principle function is feasible and useful (Sect. 3.5). 
The general, non-propositional, case is studied at a conceptual level opening 
doors to further research (Sect. 4). The authors are planning to integrate this 
function into a configurator and carry out further experiments as future work. 
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